The present preferred embodiment concerns a method and a device for reception of print data by a receiver from a sender, and in particular to mirror print jobs.
The preferred embodiment is provided for printing environments with electrophotographic high-capacity printers.
The receivers are hereby normally print servers. Such print servers are described in Chapter 15 in the book “Digitaldruck-Technik und Drucktechnologien der océ OCÉ Drucksysteme, 9th Edition, February 2005 (USBN 3-00-001019-X). These print servers are designated as océ OCÉ PRISMAproduction servers. Among other things, they establish the communication between large computing systems (mainframes) and the printing apparatuses. Such a print server can receive print data streams in different formats from multiple different mainframes and relay them to a plurality of further printing apparatuses. The transfer of the data can occur via different networks according to different protocols.
Many users of such electrophotographic high-capacity printing systems have concentrated their mainframes at one or a few sites. Often the operators of such mainframes do not implement the printing processes themselves; rather, they send their data to be printed to what are known as print centers. These print centers have one or more electrophotographic high-capacity printers that are connected with one another via a local network. A print server that receives the print data from the mainframe via an additional network (for example the Internet) is arranged in this local network.
The “Download” protocol from IBM is often used to transfer the data from a mainframe to a print server. This protocol is a feature of the IBM Print Services Facility (PSF) that can be purchased separately for the operating system OS/390 used on mainframes. Download automatically transfers print data via a TCP/IP network. An automatic error correction is executed with the Download protocol. In the event that the transfer of the print data could not be executed correctly, the print data are retransmitted. For this it is not necessary that an operator intervenes at the mainframe and re-executes the data transfer. The print data are stored in the mainframe until they have been completely and correctly transferred. Markers that are designated as checkpoints can be inserted into the print data stream generated by the mainframe. In the event that an error should occur in the transfer of the print data, the data are retransmitted again as of the last checkpoint. It is hereby not necessary to always transmit the entirety of the print data from the start.
Significant problems arise for operators of print centers when they lose the print data due to a computer malfunction or the print data are damaged to the extent that they are no longer usable. If the correct receipt has been acknowledged to the sender, it deletes the print data and they are no longer available for a retransmission. To avoid these problems, the Download protocol is provided with a function with which the print data can be simultaneously transferred to multiple receivers. This serves to transfer the print data to a print server and to mirror computer systems on which the print data are stored for a certain time in order to be able to remedy subsequently occurring errors in the processing of the print data by execution of the print data by the mirror computer system. However, the mirroring of the print data on mirror computer systems is the area of responsibility of the operator of the mainframe, not of the print centers. Even if the operator of the mainframe provides such a mirroring, the print data are deleted after the acknowledgement of the successful receipt, and there exists no possibility to re-request the print data. On the other hand, for the operator of the print center it is commercially very disadvantageous if he must re-request print data from his client that have already been correctly transmitted.
In order to avoid these problems, the print data must be stored on the mainframe or on its mirror computer systems until the complete printout has concluded. For this a confirmation to the mainframe would have occurred across the entire production chain after the successful printout so that the print data can be deleted again. Such a confirmation entails a significant communication effort. Mainframes send their print data to different print servers that in turn control a plurality of different printers. All the different print servers and printers would have to be set up for such a confirmation. Since known protocols for transfer of print data between mainframes and print servers do not provide such a confirmation, this is hardly possible in practice.
Software to mirror entire computer systems is known and could in principle also be used for such a print server that receives the print data. However, the print server would hereby have to be mirrored, which would have the result that data stored incorrectly in the print server would in turn be stored incorrectly on the mirror computer system. Problems generated by errors caused at the print server can thus not be avoided. For example, if a user at the print server accidentally deletes print data, they are also automatically deleted at the mirror computer system since this mirror computer system should represent an exact copy of the print server.
In this known software to mirror an entire computer system, every single storage process on a hardware disk of the computer system is immediately transferred to the mirror computer system and copied there.
An additional problem that the print data are sometimes transmitted to a wrong print server exists in the transmission of the print data. The individual print servers often have similar names, such that a wrong print server is input as a target given a typo or given an incorrect selection from a menu list. Although such a mis-addressing does not occur frequently, when it occurs it causes significant losses in high-capacity printing since a print product printed out at the wrong printing apparatus is for the most part unusable. If print data are transmitted to a wrong printing apparatus, the correct resources and form definitions are often not present, such that the print data are incorrectly printed out. In high-capacity printing, an incorrectly printed print job can mean a significant financial loss. It has previously been sought to establish such an incorrect transmission of print data by means of firewall programs that—using parameters that are contained in the header of the employed network protocol—decide whether the print data have been correctly forwarded. However, the headers of the network protocols (for example TCP/IP) contain only basic parameters such as the address of the sender and of the receiver. If a specific sender is cleared at a specific receiver, the firewall programs allow the receipt of all data from this sender.
However, a significantly more specific association between sender and receiver is often desired; for example, a sender should transmit a specific type of print job to a specific receiver and transmit a different type of print job to a different receiver.
In print servers based on Linux systems or other Unix derivatives it is known to check incoming print jobs by means of the protocol LP with the deamon lpd.perms for multiple parameters specific to the sender and receiver. For this a separate file that contains not only the address data of the sending computer and of the receiving computer but also multiple parameters regarding the user is respectively attached to the print job. A parameter regarding the printing apparatus is also listed therein.
It is disadvantageous in this system that the parameters to be monitored are stored in a separate file. If a hacker receives and copies this file, he can initiate a print job at a print server at any time. He can also introduce files into the print server that represent a security risk.
A server system designated with the trade name Océ PRISMAproduction emerges from “Digital Printing—Technology und [sic] Printing Techniques of Océ Digital Printing Presses” (I.I.c.) that processes or converts a broad palette of data structures that are then printed on IPDS printers. The Océ PRISMAproduction server system comprises a print job manager PJM (see Chapters 15.2.4 and 18.2) with which print jobs are generated at an arbitrary customer client and are executed and administered in this server system. The print job manager is also designated as a print order manager.
German Patent Application DE 10 2007 009 737 filed on 28 Feb. 2007 is referenced, and it is incorporated herein.
The method described therein processes job chaperone data of a print job that contain control parameters to control the print job. This method is executed in a printing system with a print job manager, one or more clients at which print jobs are generated, and a print server to supply the print jobs to a printing apparatus, and comprises the following steps:                receive a print job with job chaperone data from one of the clients via the print job manager,        check the job chaperone data according to predetermined ticket rules and output a printing system-specific job ticket, and        relay the print job with the job ticket to the print server.        
This method is characterized in that the checking of the job chaperone data is centrally executed at the print job manager according to the predetermined ticket rules.
Since the job chaperone data are centrally (and advantageously exclusively) checked or monitored at the print job manager, the ticket rules applied for a specific print job can be reconstructed simply because the ticket rules are present only at a single location (namely the print job manager) and not, as was previously the case, at the most different clients, and the ticket rules can respectively be examined there at the print job manager. Furthermore, via the central execution of the inspection of the job chaperone data at the print job manager it is ensured that all incoming job chaperone data are inspected according to the same ticket rules and are correspondingly modified and corrected as necessary.
Furthermore, the ticket rules are to be centrally administered via the central execution of the inspection of the job chaperone data, whereby they can also be centrally monitored, and it is avoided that similar job chaperone data or similar errors in job chaperone data are corrected differently.
An additional advantage of the central inspection of the job chaperone data at the print job manager is that the inspection of the job chaperone data occurs very close to the concrete printing apparatus in the process chain, such that this inspection can be conducted very specifically for the respective printing apparatus. The quality of the inspection can hereby be significantly increased. Given the execution of the job chaperone data at the clients the problem exists that the clients can communicate with different print job managers, such that an inspection of the job chaperone data that is executed at the clients must be adapted to the printing apparatuses that can be reached with the different print job managers, which again is very difficult.
Via the central administration of the ticket rules it is also possible to provide the operator with tools that facilitate the generation and administration of the ticket rules. It is in particular appropriate to provide a graphical user interface (GUI) in which the ticket rules can be generated and administered, and to provide a software module with which the syntax of the edited ticket rules is automatically checked for a correct syntax.